Network packet brokers (NPBs) have long been employed to facilitate processing of data packets and/or to route data packets to desired destinations. In an example application, NPBs may be employed IO mirror and/or route traffic to monitoring tools. These monitoring tools may include, for example, network analysis tools, forensic tools, various network monitoring tools, firewalls, malware prevention tools, intrusion detection tools, etc.
In an example, NPBs represent hardware and/or software modules that perform, among other tasks, aggregation of monitored traffic (which may be the original data packets or replicated copies thereof) from multiple links/segments, filtering and grooming of traffic to relieve overburdened monitoring tools, load-balancing traffic across a pool of monitoring tools, and regeneration of traffic to multiple monitoring tools. NPBs are available from vendors such as Ixia Corporation of Calabasas, Calif.
FIG. 1 illustrates a typical NPB application, which receives traffic from the network conceptually represented by a combination of router 102, switch or tap 104 and switch 106. Switch or tap 104 represents the device to copy or redirect traffic traversing router 102 and switch 106 to input port 108 of NPB 130. In the example of FIG. 1, the destinations for NPB traffic may represent, without limitation, network testing, monitoring, and analysis tools. These are shown as test tools 122, 124, 126, and 128 of FIG. 1.
The operator, typically a network engineer or network administrator and not shown explicitly in FIG. 1, configures fitters (such as 110) and load balancers (such as 112) of the NPB (130) to select the traffic received via one or more input ports 108 in order to direct the selected traffic to particular destinations (e.g., either one or more of tools 122, 124, 126, and 128 via ports 114, 116, 118 and 120).
Generally speaking, filters (such as 110) select traffic based on various criteria, including for example, specific IP addresses or specific protocols designated in a traffic packet's header portion and send those packets to a specific destination (port). The ports are shown as ports 114, 116, 118 or 120 in FIG. 1.
Load balancers (such as 112) tend have the additional or alternative function of distributing selected packets over a number of destinations, usually with the goal of sending an equal number of packets to each destination or in accordance with some weighting methodology. For example, if a load balancer selects 100 packets and has 4 destinations, the goal of a load balancer aiming to distribute the packets evenly among the four destinations would be to send 25 of the selected packets to each port.
When deploying an NPB solution, operators must develop the appropriate filters and load balancers, which may be simple or highly complex. To ensure proper operation, operators need to validate the accuracy of the filters and load balancers before these filters and load balancers may be deployed in a production environment. This is because incorrect filters or load balancers may have mild to severe negative impacts on network traffic, and thus on the critical business applications which rely on accurately processed network traffic, and thus on the business itself.
In the prior art, filter and load balancer validation of a NPB has typically been accomplished by configuring hardware test equipment and the NPB in a lab environment. FIG. 2 illustrates a typical NPB validation environment. A traffic generator 206 is typically used to send traffic into the NPB input ports (represented by input port 204) of NPB 210, and a protocol analyzer 216 is used to capture the traffic from the NPB output ports (represented by one or more of output ports 214, 218, 220 and/or 222). The traffic generator 206 and protocol analyzer functions 216 may be included in a single tool or “box” or in different tools or boxes.
Alternately, the traffic generator 206 could be a tap or span port from a live network, but typically NOT the production network during testing because of the need to isolate the production network from the test environment to prevent any possible business disruption.
Alternately, the protocol analyzer 216 could be a copy of the actual test tool that will be used in the production environment.
In an example, the protocol analyzer could be a software tool such as the open source product Wireshark (www.wireshark.org) executing on a standard personal computer such as a desktop or laptop computer although this approach normally suffers from poor performance for the hardware testing environment of FIG. 2.
The NPB filters (such as 208) and load balancers (such as 212) are then validated by (1) configuring the filters and load balancers and other set-up requirements in the NPB, (2) creating traffic using the traffic generator to cause the traffic to enter the input port of the NPB, (3) capturing the traffic with the protocol analyzer, and (4) manually examining the captured traffic to determine if the filters and load balancers produced the desired result.
However, this approach suffers many disadvantages. For example, it is necessary to procure and configure the traffic generator, NPB, and protocol analyzer. The procurement of these devices may be expensive. This is because traffic generators, NPBs, and protocol analyzers are typically expensive pieces of equipment, typically costing tens or hundreds of thousands of dollars.
Therefore a large investment is often required to validate the NPBs in the prior art. Due to the large investment required, these equipment tend to be a limited resource in any given enterprise such that time spent using the equipment may be costly and on short allocation, potentially delaying filter and load balancer validation and thus NPB deployment.
Further, the configuration tasks may be complex and time-consuming, and require expert skills. Such expert skills tend to be in short supply in any given enterprise, as may be expected.
Additionally, the validation turn-around time is significant using the prior art approach and directly affects the overall time it takes to validate the filters and load balancers. For example, test validation may require multiple cycles of changing filters and load balancers, modifying configurations of the filters and load balancers, programming the traffic generator for new traffic, and moving cables to different ports on the NPB, etc. Some of these tasks may require the validation testers to physically move from in front of the computer console (where testing is run) to the equipment room where the hardware is implemented to make changes. These multiple cycles are typically necessary to, for example, debug the implementation of the filters and/or load balancers, to test their performance using different types of traffic and different traffic loads, to verify their performance using different tests, etc. The complexity of these tasks and the time-consuming steps required during each test cycle increase the overall time it takes to complete the validation test.
Decreasing the complexity of the test environment, reducing the need for expensive equipment, and/or speeding up the test iteration turn-around time in order to speed up NPB validation and thus speeding up NPB deployment are some of the goals of various embodiments of the present invention.